home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
4_1_07.tro
< prev
next >
Wrap
Text File
|
1991-12-13
|
33KB
|
1,745 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright ( c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v | 5i'
.sp 2P
.LP
\fBRecommendation\ M.251\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBMAINTENANCE\ FUNCTIONS\ TO\ BE\ IMPLEMENTED\ IN\ CCITT\(hyMML\fR
.FS
This
Recommendation is not yet complete, a number of items are for continuing
studies.
.FE
.EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.251''
.OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.251 %'
.ce 0
.sp 1P
.LP
\fB1\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation identifies the maintenance functions to be
controlled by means of the CCITT\(hyMML.
.PP
The CCITT\(hyMML (man\(hymachine language) is intended to handle the
functions required to manage telecommunication systems, e.g.\ via a
telecommunication management network (TMN) (see Recommendation\ M.30). The
man\(hymachine
interface (MMI) enables the exchange of information between users and systems
encoded in MML.
.PP
Interaction between the users and the controlled systems is based on a
repertoire of inputs, outputs, special actions and man\(hymachine interaction
mechanisms, including dialogue procedures.
.PP
This Recommendation deals with the specification and control of
maintenance functions. The tests appropriate to particular maintenance
functions remain as described in the relevant M\(hyseries Recommendations.
.PP
When defining MML\(hyfunctions the tasks which need to be performed
(jobs) are first identified, in order to derive system functions to be
controlled.
.PP
The relationship between jobs, system functions and MML\(hyfunctions is
described in \(sc\ 1.2 of Recommendation\ M.250.
.PP
For each system function, one or more MML\(hyfunctions are derived. Each
MML\(hyfunction is then described using the \*Qmeta\(hylanguage\*U defined
in
Recommendation\ Z.333\ [1], which permits the information structure to
be defined in detail
.FS
For further studies, other methodologies than those described
in\ Z.333\ [1] may be considered.
.FE
. MML\(hyfunctions do not necessarily
represent the actual command structure of any real implementation of the
man\(hymachine language.
.PP
Each of the MML\(hyfunctions could be implemented by providing a separate
and distinctive command, or several MML\(hyfunctions could be implemented
using a single command.
.RT
.sp 2P
.LP
\fB2\fR \fBSystem functions\fR
.sp 1P
.RT
.PP
System functions can often be categorized and divided to break down a task
and simplify the implementation and control of such functions by the use
of MML.
.PP
An example showing the generalized functional architecture for a TMN is
given in Figure\ 1/M.251. The MML will be implemented at the g\ reference
point.
.PP
Maintenance functions are related to the network element functions, as
well as to the TMN general functions and TMN application functions as defined
in Recommendation\ M.30.
.PP
This complex of maintenance functions are to be described in two
ways:
.RT
.LP
i)
on the basis of the \*Qmaintenance phases\*U of
Recommendation\ M.20;
.LP
ii)
the rest (under study).
.sp 2P
.LP
\fB3\fR \fBScope\fR
.sp 1P
.RT
.PP
The term \*Qmaintenance\*U covers all aspects which have to do with
failures, such as supervision, detection, localization, information,
repair,\ etc.
.PP
The general concepts and philosophy are fully described in
Recommendation\ M.20. The description of the maintenance functions on the
basis of Recommendation\ M.20 has the advantage that general descriptions
of the
various maintenance activities are obtained, valid for all network elements.
In this case no separate descriptions for maintenance of \*Qterminals\*U,
\*Qsubscriber lines\*U, \*Qexchanges\*U, \*Qlines between exchanges\*U,\
etc. are necessary.
.bp
.RT
.LP
.rs
.sp 39P
.ad r
\fBFigure 1/M.251, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB4\fR \fBMaintenance functions in the various maintenance phases\fR
.sp 1P
.RT
.PP
The maintenance functions and their relationship to the maintenance phases,
defined in \(sc\ 4 of Recommendation\ M.20, are listed in
Table\ 1/M.251.
.RT
.PP
These maintenance functions have to be described; the status of
these descriptions are given below:
.sp 1P
.LP
4.1
\fIFailure detection\fR
.sp 9p
.RT
.LP
4.1.1
\fIContinuous checking\fR \
(see Note)
.LP
4.1.2
\fIRoutine or periodic testing\fR \
(see Note)
.LP
4.1.3
\fIChecking in live traffic\fR \
(see Note)
.LP
4.1.4
\fIChecking in absence of live traffic\fR \
(see Note)
.bp
.LP
.ce
\fBH.T. [T1.251]\fR
.ce
TABLE\ 1/M.251
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(114p) | cw(114p) .
Maintenance phases Maintenance functions
_
.T&
lw(114p) | lw(114p) .
1 Failure detection {
1.1
Continuous checking
1.2
Routine or periodic testing
1.3
Checking in live traffic
1.4
Checking in absence of live traffic
}
_
.T&
lw(114p) | lw(114p) .
2 System protection
_
.T&
lw(114p) | lw(114p) .
3 Failure information
_
.T&
lw(114p) | lw(114p) .
4 Failure localization {
4.1
Assembling alarm messages
4.2
Request for failure information
4.3
Test/Measurement
4.4
Setting of loops
}
_
.T&
lw(114p) | lw(114p) .
5 Failure correction
_
.T&
lw(114p) | lw(114p) .
6 Verification 6.1 Test/Measurement
_
.T&
lw(114p) | lw(114p) .
7 Restoration 7.1 Deblocking
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 1/M.251 [T1.251], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 2
4.2
\fISystem protection\fR \
(under study)
.sp 9p
.RT
.sp 1P
.LP
4.3
\fIFailure information\fR \
(under study; e.g.\ change of alarm levels)
.sp 9p
.RT
.sp 1P
.LP
4.4
\fIFailure location\fR
.sp 9p
.RT
.LP
4.4.1
\fIAssembling alarm messages\fR \
(under study)
.LP
4.4.2
\fIRequest for failure information\fR \
(under study)
.LP
4.4.3
\fITest/measurement\fR \
(see Note)
.LP
4.4.4
\fISetting of loops\fR \
(under study)
.sp 1P
.LP
4.5
\fIFailure correction\fR \
(under study)
.sp 9p
.RT
.sp 1P
.LP
4.6
\fIVerification\fR
.sp 9p
.RT
.LP
4.6.1
\fITest/measurement\fR \
(see Note)
.sp 1P
.LP
4.7
\fIRestoration\fR
.sp 9p
.RT
.LP
4.7.1
\fIDeblocking\fR \
(under study)
.PP
\fINote\fR \ \(em\ As far as these functions are controlled by MML, they
are covered by Annex\ A (whether the totality has been covered is still
under
study).
.sp 2P
.LP
\fB5\fR \fBOther maintenance functions\fR
.sp 1P
.RT
.PP
The maintenance functions in the areas of support of maintenance, of failure
statistics and of preventive maintenance are under study.
.RT
.sp 2P
.LP
\fB6\fR \fBRelation to Recommendation Z.331 \*QMaintenance functions\*U\fR
.sp 1P
.RT
.PP
In Recommendation Z.331 [2], a list is given of maintenance
functions. Items of that list which are covered, in a general way, by this
Recommendation are listed in Table\ 2/M.251.
.bp
.RT
.ce
\fBH.T. [T2.251]\fR
.ce
TABLE\ 2/M.251
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(168p) | cw(60p) .
Maintenance functions {
Covered in this
Recommendation
}
_
.T&
lw(168p) | lw(60p) .
{
\fIMaintenance of subscribers' lines\fR
}
.T&
lw(168p) | lw(60p) .
{
Testing one subscriber line and associated equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Testing a group of subscriber lines and associated equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Measuring one subscriber line and associated equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Measuring a group of subscriber lines and associated equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Blocking or unblocking a subscriber line for maintenance
} Under study
.T&
lw(168p) | lw(60p) .
{
Observing or supervising subscriber lines and equipment
} Under study
.T&
lw(168p) | lw(60p) .
{
\fIMaintenance of circuits between exchanges and associated equipment\fR
}
.T&
lw(168p) | lw(60p) .
{
Testing/Measuring one or group circuit(s) and associated equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Observing and supervising circuit(s) and associated equipment
} Under study
.T&
lw(168p) | lw(60p) .
{
Control the status of one or group circuit(s)
} Under study
.T&
lw(168p) | lw(60p) .
Analyzing maintenance data Under study
.T&
lw(168p) | lw(60p) .
{
Administering and controlling maintenance reports
} Under study
.T&
lw(168p) | lw(60p) .
{
\fISwitching network maintenance\fR
}
.T&
lw(168p) | lw(60p) .
Making test calls Yes
.T&
lw(168p) | lw(60p) .
Initiating a call trace Yes
.T&
lw(168p) | lw(60p) .
Holding faulty connections Under study
.T&
lw(168p) | lw(60p) .
{
Testing and measuring peripheral equipment
} Yes
.T&
lw(168p) | lw(60p) .
{
Testing and measuring switching units
} Yes
.T&
lw(168p) | lw(60p) .
{
Reducing service for low priority subscribers
} Under study
.T&
lw(168p) | lw(60p) .
{
Setting up a connection via a specific path
} Under study
.T&
lw(168p) | lw(60p) .
{
Supervising and measuring the Quality of Service
} Yes
.T&
lw(168p) | lw(60p) .
{
Localizing faults in the speech path
} Yes
.T&
lw(168p) | lw(60p) .
{
Providing access for traffic observations for maintenance
} Under study
.T&
lw(168p) | lw(60p) .
Reporting alarms Under study
.T&
lw(168p) | lw(60p) .
{
Recording switching unit status
} Under study
.T&
lw(168p) | lw(60p) .
{
\fIControl system maintenance\fR
}
.T&
lw(168p) | lw(60p) .
Reporting system status Under study
.T&
lw(168p) | lw(60p) .
Reporting alarms Under study
.T&
lw(168p) | lw(60p) .
Localizing faults Yes
.T&
lw(168p) | lw(60p) .
{
Testing on a functional basis after repair
} Yes
.T&
lw(168p) | lw(60p) .
{
Initiating periodic testing operations
} Yes
.T&
lw(168p) | lw(60p) .
{
Changing system configuration for maintenance
} Under study
.T&
lw(168p) | lw(60p) .
Checking consistency of data Under study
.T&
lw(168p) | lw(60p) .
Initiating restart Under study
.T&
lw(168p) | lw(60p) .
{
Setting traps for programme faults tracing
} Under study
.T&
lw(168p) | lw(60p) .
Changing memory contents Under study
.T&
lw(168p) | lw(60p) .
{
Memory dumping for maintenance purposes
} Under study
.T&
lw(168p) | lw(60p) .
{
Controlling overload parameters
} Under study
.T&
lw(168p) | lw(60p) .
{
Changing the criteria for degradation of service
} Under study
.T&
lw(168p) | lw(60p) .
{
Reducing service for low\(hypriority subscribers
} Under study
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 2/M.251 [T2.251], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB7\fR \fBDescription of maintenance functions in annexes to this
Recommendation\fR
.sp 1P
.RT
.LP
Annex\ A\ \(em\ General description of maintenance
tests/measurements
.LP
Annex\ B\ \(em\ General description of failure information (under
study)
.LP
Annex\ C\ \(em\ Protection, restoration (under study)
.LP
Annex\ D\ \(em\ Support of maintenance (under study).
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation M.251)
.sp 9p
.RT
.ce 0
.ce 1000
\fBGeneral description of\fR
\fBmaintenance tests/measurements\fR
.sp 1P
.RT
.ce 0
.LP
A.1\fR \fIIntroduction\fR
.sp 1P
.RT
.PP
One of the purposes of maintenance is to detect, localize and
repair failures.
.PP
Failures can be detected by means of different methods, one of them
being tests/measurements.
.PP
The following description of tests/measurements is valid for all
objects in a network. An object being defined for this purpose is anything
in the network upon which a test/measurement can be performed.
.PP
This description has been made according to
Recommendation\ Z.332\ [3].
.RT
.LP
A.2
\fITests and measurements\fR
.sp 1P
.RT
.sp 2P
.LP
A.2.1
\fIDocument A\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.1.1\ \ \fIIntroduction\fR
.sp 9p
.RT
.PP
Maintenance tests and/or measurements may be performed on a demand and
routine basis, according to the maintenance strategies.
.RT
.LP
A.2.1.2\ \ \fIList of class B functions\fR
.sp 1P
.RT
.sp 2P
.LP
A.2.1.2.1\ \ \fITests/measurements\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.1.3\ \ \fIList of jobs\fR
.sp 9p
.RT
.sp 1P
.LP
A.2.1.3.1\ \ \fIPlan a routine test/measurement\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to create (or change) a list of
tests and test programmes containing all of the data necessary
for the test/measurements to be run successfully and to identify
the objects on which the tests/measurements are to be run.
.LP
\(em
The system is supposed to record all of the necessary data
and create (or change) required test/measurement sets.
.LP
\(em
The user is supposed to introduce all the data needed.
.LP
\(em
The complexity of the job may be high depending on the amount
of data to be introduced.
.LP
\(em
The frequency of the job is very low.
.LP
\(em
The job is supposed to be performed at network and/or
OMC level.
.sp 1P
.LP
A.2.1.3.2\ \ \fIDefine/change/delete the schedule of routine\fR \fItests/measurements\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to schedule new (or change/delete
existing) routine tests/measurements depending on the number and
types of objects to be tested/measured and the availibility of
test equipment and test functions.
.LP
\(em
The system is supposed to schedule (or change/delete) the
requested tests/measurements according to the schedule input by
the user.
.bp
.LP
\(em
The user is supposed to input the test/measurement types and
related data (test/measurement sets information) and time
parameters, such as start time, stop time,\ etc., in order to
obtain the required schedule.
.LP
\(em
The complexity of the job is medium.
.LP
\(em
The frequency of the job is low.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.PP
\fINote\fR \ \(em\ Change of the schedule may be done by a combination of
deleting the schedule in use and defining a new one.
.sp 1P
.LP
A.2.1.3.3\ \ \fIActivate the execution of routine tests/measurements\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to perform a routine
test/measurement according to a specified schedule. This allows
the verification on a routine basis of the correct functioning
of one or more objects.
.LP
\(em
The system is supposed to perform the tests/measurements
according to the specified schedule. The results may be stored
within the system for later analysis and/or output or routed to
a designated hardcopy device. The system may also be required to
provide an output error message if it is unable to perform some
of the requested tests/measurements.
.LP
\(em
The user may be required to input variables such as schedule
identity, start time, stop time and a start point for a series
of tests/measurements.
.LP
\(em
The complexity of the job is low.
.LP
\(em
The frequency of the job is medium.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 1P
.LP
A.2.1.3.4\ \ \fIStop/suspend the execution of a certain routine\fR
\fItest/measurement\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to stop/suspend the execution of
the test/measurement before the scheduled stop time.
.LP
\(em
The system is supposed to stop/suspend the execution of the
test/measurement according to the time data introduced by the
user.
.LP
\(em
The user is supposed to introduce the identity of the test
measurement to be stopped/suspended and the time data of the
actual stop/suspension.
.LP
\(em
The complexity of the job is low.
.LP
\(em
The frequency of the job is low.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 1P
.LP
A.2.1.3.5\ \ \fIActivate the execution of on\(hydemand tests/measurements\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to perform on\(hydemand
tests/measurements on one or more objects in order to verify
the correct functioning of the object(s).
.LP
\(em
The system is supposed to perform the actions requested on
the specified objects as soon as possible. As many of the system
parameters as possible should be system resident. The results
may de displayed to the user, stored within the system and/or
routed to hardcopy devices depending on the routing control
information. The system should output an error message (or code)
if it is unable to perform the requested test/measurement.
.LP
\(em
The user is supposed to input the type of the
test/measurement and the identities of the objects to be
tested/measured. The user may also have to input relevant
parameters. These would normally be modifications of the system
resident default values for a particular test/measurement
execution
(e.g., the number of times the test/measurement is
retried).
.LP
\(em
The complexity of the job is low, unless the user has to
input a large number of parameters values.
.LP
\(em
The frequency of the job is high.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 1P
.LP
A.2.1.3.6\ \ \fIDelete one or more obsolete test/measurement data\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to delete the data related to a
certain test/measurement component which are of no more
interest.
.LP
\(em
The system is supposed to delete the specified data,
providing the necessary safety strategies.
.LP
\(em
The user is supposed to specify the identity of the data to
be deleted.
.bp
.LP
\(em
The complexity of the job is low.
.LP
\(em
The frequency of the job is low.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 1P
.LP
A.2.1.3.7\ \ \fIRetrieve relevant data of tests/measurements\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to retrieve information on the
tests and/or measurements that are currently defined in the
system.
.LP
\(em
The system is supposed to provide to the user the requested
information.
.LP
\(em
The user is supposed to identify the requested information.
.LP
\(em
The complexity of the job is low.
.LP
\(em
The frequency of the job is high.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 1P
.LP
A.2.1.3.8\ \ \fIRetrieve the results of tests and/or of measurements already\fR
\fIperformed\fR
.sp 9p
.RT
.LP
\(em
The purpose of the job is to retrieve the recorded results in
order to examine them.
.LP
\(em
The system is supposed to provide to the user the requested
information.
.LP
\(em
The user is supposed to introduce the identity of the items
to be displayed.
.LP
\(em
The complexity of the job is low.
.LP
\(em
The frequency of the job is high.
.LP
\(em
The job is supposed to be performed at network and/or OMC
level.
.sp 2P
.LP
A.2.2
\fIDocument B\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.2.1\ \ \fR \fIIntroduction\fR
.sp 9p
.RT
.PP
The model in Figure A\(hy1/M.251 describes in a general (function
independent) way those system functions called tests/measurements which
can be controlled by the user by means of MML functions.
.PP
This model can be applied to measurements as well as to tests for
maintenance purposes.
.RT
.sp 2P
.LP
A.2.2.2\ \ \fIMaintenance test/measurement model\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.2.2.1\ \ \fITest/measurment elements\fR
.sp 9p
.RT
.PP
A test/measurement is identified by three basic elements: time,
entities, objects (when, what, where).
.PP
\fITime\fR includes all necessary information to define the start, the
duration and periodicity of a certain test/measurement.
.PP
\fIEntities\fR describe the quantities for which data collection must be
performed with a certain test/measurement, e.g.\ loss, noise, gain/slope,
signalling performance,\ etc.
.PP
\fIObjects\fR are intended as individual items within each object type
on which the tests/measurements are performed. Examples of objects types
are
circuits, group of circuits, transmission equipment, facilities,\ etc.
.RT
.sp 1P
.LP
A.2.2.2.2\ \ \fITest/measurement matrix\fR
.sp 9p
.RT
.PP
The definition of tests/measurements is based on an abstract model which
contains the definition of a test/measurement matrix (see
Figure\ A\(hy1/M.251), in which each row represents one uniquely definable
entity, e.g.\ transmission loss/noise test, and each column represents
a uniquely
definable object type, e.g.\ a group of circuits, a destination.
.RT
.PP
A certain combination of entities and object types corresponds to certain
entities in the test/measurement matrix and forms a test/measurement
type.
.PP
It is recognized that part of these test/measurement types may be
standardized while the rest of them could be system and/or administration
dependent. It should be noted that not all the entries in the test/measurement
matrix can be used because some of them will be meaningless (e.g.\ signalling
tests on incoming circuits).
.bp
.RT
.LP
.rs
.sp 21P
.ad r
\fBFigure A\(hy1/M.251, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
A single object is defined by its type and/or its individual
object
identity. In some test/measurement types the number of the objects is fixed,
in other types one can choose, for the actual test/measurement, some or
all the
allowed objects by means of administration MML commands. Chosen (selected)
objects form an object list.
.PP
The object identity contains all necessary information to identify
the address of the object in any part of the network (e.g.\ node\(hyaddress,
exchange\(hyaddress,\ etc.).
.PP
The structure of division of object types and entities is open\(hyended
in such a way that any new object type or entity may be added.
.PP
If the start of a test/measurement is instantaneous, it can also be
called \*Qon\(hydemand\*U or \*Q
one\(hyshot\*U test/measurement
.
.RT
.sp 1P
.LP
A.2.2.2.3\ \ \fIBasic categories of tests/measurements\fR
.sp 9p
.RT
.PP
Two basic categories of tests/measurements are envisaged (see
Figure\ A\(hy2/M.251). The category\ A is a test/measurement of undetermined
duration while the category\ B is intended to be performed only for a
predetermined duration.
.PP
The start of a test/measurement may be intended as instantaneous or
delayed for a defined time duration\ \(*D\fIt\fR\d1\ufrom the activation of the
measurement. Since the stop time of a measurement of category. A\ is not
given when the test/measurement is activated or created, it has to be given
during
the test/measurement unless the test/measurement is intended to go on
forever.
.PP
When deactivation is requested, there may be a defined delay
of\ \(*D\fIt\fR\d2\ubefore the test/measurement is stopped. In the creation of a
test/measurement, a start time optionally be provided, in which case for
that particular test/measurement, the activation function is not necessary.
.PP
Time parameters needed to control a test/measurement can be divided
into three groups:
.RT
.LP
1)
test/measurement type dependent time parameters (interval
parameters of a test/measurement type, e.g\ repeat test
interval)
.FS
A
repeat test interval
is the minimum time
interval before the repetition of a test can be
attempted.
.FE
;
.LP
2)
test/measurement dependent time parameters (e.g.\ time
parameters which define the periodicity of test measurement).
These parameters refer always to relative time or specific
dates;
.LP
3)
test/measurement independent time parameters (e.g.\ time
parameters which are related to the actual start or stop of a
certain test/measurement in activation and deactivation
functions).
.bp
.LP
.rs
.sp 33P
.ad r
\fBFigure A\(hy2/M.251, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
A.2.2.2.4\ \
\fIStructure of a test/measurement\fR
.sp 9p
.RT
.PP
A test/measurement consists of:
.RT
.LP
\(em
test/measurement set information;
.LP
\(em
time information;
.LP
\(em
output routing information.
.PP
Figure A\(hy3/M.251 shows a model relating these parameters to
maintenance tests/measurements. This model is useful in illustrating the
relationships between test/measurement sequences (test/measurement sets),
time parameters, some of which relate to routing tests only (i.e., they
have no
relevance to on\(hydemand tests/measurements) and the specification of output
media [which can be assumed to be according to the specification of the
output destination(s)].
.PP
Test/measurement set information, time information, output media
information as well as object lists may be predefined. It should be noted
that predefinition characteristics are system dependent.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure A\(hy3/M.251, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
A.2.2.2.4.1\ \
\fITest/measurement set information\fR
.sp 9p
.RT
.PP
Test/measurement set information consists of one or more selected test/measurement
types with defined objects (object lists) and
test/measurement type dependent parameters.
.PP
Note that normally, for maintenance purposes, test/measurement types are
fixed at a given moment in time and that they cannot be created, deleted
or changed by MML commands; only later supplier releases may change these
test/measurement types according to new requirements.
.PP
It is recognized that the Administrations may require MML functions to
administer test/measurement types, grouping predefined entities with object
types. Such functions should be considered as a system extension and upgrade
function and, therefore, should belong to the system control function area.
However, due to the fact that system control functions are not yet recommended,
they are included in the subsequent descriptions.
.RT
.sp 1P
.LP
A.2.2.2.4.2\ \
\fITime information\fR
.sp 9p
.RT
.PP
Tests/measurements of categories A and B (see Figure\ A\(hy2/M.251) may
perform continuous recording or recording on predetermined days (recording
days).
.PP
For tests/measurements performing continuous recording, only the start
date is needed.
.RT
.sp 1P
.LP
A.2.2.2.4.3\ \
\fIOutput routing information\fR
.sp 9p
.RT
.PP
Output routing information defines the output destinations (there may be
more than one), the output formats and the number of copies required. An
output destination may be an internal (system resident) log or file. This
file may be analyzed at a later time and its data used to provide reports
both to
the users and for administrative purposes.
.RT
.sp 1P
.LP
A.2.2.2.4.4\ \ \fISummary\fR
.sp 9p
.RT
.PP
Test/measurement set information, time information, output routing information
as well as object lists may be predefined. It should be noted that predefinition
characteristics are normally system dependent.
.bp
.RT
.sp 2P
.LP
A.2.3
\fIDocument C\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.3.1\ \ \fIList of MML functions\fR
.sp 9p
.RT
.LP
1)
\fICreation\fR
.LP
\(em
create a test/measurement set
.LP
\(em
create a list of objects
.LP
\(em
create a time data list
.LP
\(em
create an output media list
.LP
\(em
create a routine test/measurement
.LP
2)
\fIChanging\fR
.LP
\(em
change a test/measurement set
.LP
\(em
change a list of objects
.LP
\(em
change a time data list
.LP
\(em
change an output media list
.LP
\(em
change a routine test/measurement
.LP
3)
\fIDeletion\fR
.LP
\(em
delete a test/measurement set
.LP
\(em
delete a list of objects
.LP
\(em
delete a time data list
.LP
\(em
delete an output media list
.LP
\(em
delete a routine test/measurement
.LP
4)
\fIInterrogation\fR
.LP
\(em
interrogate a test/measurement set
.LP
\(em
interrogate a list of objects
.LP
\(em
interrogate a time data list
.LP
\(em
interrogate an output media list
.LP
\(em
interrogate a routine test/measurement
.LP
5)
\fIActivation\fR
.LP
\(em
activate a routine test/measurement
.LP
\(em
activate an on\(hydemand test/measurement
.LP
6)
\fIDeactivation\fR
.LP
\(em
deactivate a routine test/measurement
.LP
\(em
deactivate an on\(hydemand test/measurement
.LP
7)
\fIOutput\fR
.LP
\(em
output the results of a routine test/measurement
.LP
\(em
output the results of an on\(hydemand test/measurement
.LP
8)
\fIAdministration of test/measurement types\fR
.LP
\(em
create a test/measurement type
.LP
\(em
change a test/measurement type
.LP
\(em
delete a test/measurement type
.PP
\fINote\fR \ \(em\ These functions are not yet recommended, but are
included, so that Administrations are able to consider the management of
different test/measurement types.
.sp 2P
.LP
A.2.4
\fIDocument D\fR
.sp 1P
.RT
.sp 1P
.LP
A.2.4.1\ \ \fIIntroduction\fR
.sp 9p
.RT
.PP
All the information entities needed for the MML functions related to the
maintenance tests administration have been identified and are reported
in this Document\ D by means of diagrams representing each MML function
information structure. See Figures\ A\(hy5/M.251 to\ A\(hy35/M.251. The same
information structure diagrams apply to maintenance measurements administration
functions.
.PP
A schematic overview of these functions is given in
Figure\ A\(hy4/M.251.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy4/M.251, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
A.2.4.2\ \ \fIInformation structure diagrams for each MML function\fR
.sp 9p
.RT
.LP
.rs
.sp 25P
.ad r
\fBFigure A\(hy5/M.251, p.8\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 21P
.ad r
\fBFigure A\(hy6/M.251, p.9\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 13P
.ad r
\fBFigure A\(hy7/M.251, p.10\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 18P
.ad r
\fBFigure A\(hy8/M.251, p.11\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure A\(hy9/M.251, p.12\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy10/M.251, p.13\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy11/M.251, p.14\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy12/M.251, p.15\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy13/M.251, p.16\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy14/M.251, p.17\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 27P
.ad r
\fBFigure A\(hy15/M.251, p.18\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 4P
.ad r
\fBFigure A\(hy16/M.251, p.19\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure A\(hy17/M.251, p.20\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 15P
.ad r
\fBFigure A\(hy18/M.251, p.21\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 15P
.ad r
\fBFigure A\(hy19/M.251, p.22\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 15P
.ad r
\fBFigure A\(hy20/M.251, p.23\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 21P
.ad r
\fBFigure A\(hy21/M.251, p.24\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 25P
.ad r
\fBFigure A\(hy22/M.251, p.25\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 25P
.ad r
\fBFigure A\(hy23/M.251, p.26\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 23P
.ad r
\fBFigure A\(hy24/M.251, p.27\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 21P
.ad r
\fBFigure A\(hy25/M.251, p.28\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 26P
.ad r
\fBFigure A\(hy26/M.251, p.29\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure A\(hy27/M.251, p.30\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 24P
.ad r
\fBFigure A\(hy28/M.251, p.31\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure A\(hy29/M.251, p.32\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 4P
.ad r
\fBFigure A\(hy30/M.251, p.33\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 24P
.ad r
\fBFigure A\(hy31/M.251, p.34\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 4P
.ad r
\fBFigure A\(hy32/M.251, p.35\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 16P
.ad r
\fBFigure A\(hy33/M.251, p.36\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 23P
.ad r
\fBFigure A\(hy34/M.251, p.37\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure A\(hy35/M.251, p.38\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
A.2.5
\fIDocument G\fR
.sp 9p
.RT
.PP
Glossary of used terms
.FS
This list is the subject of
further study.
.FE
:
.RT
.LP
a)
\fBstart/stop date\fR \ \(em\ The start/stop day of a
test/measurement on a routine basis.
.LP
b)
\fBstart/stop time\fR \ \(em\ The start/stop time of a
test/measurement on a routine basis.
.LP
c)
\fBtest/measurement day\fR \ \(em\ Day in which the
test/measurement is performed according to the associated
schedule.
.LP
d)
\fBobjects\fR \ \(em\ Individual items on which test/measurements
are performed (e.g.\ circuits, group of circuits, transmission
equipments,\ etc.)
.LP
e)
\fBOMC\fR \ \(em\ Operation and maintenance centre.
\v'2P'
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation M.251)
.sp 9p
.RT
.ce 0
.ce 1000
\fBGeneral description of failure information\fR
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
(under study)
\v'2P'
.ce 0
.sp 1P
.ce 1000
ANNEX\ C
.ce 0
.ce 1000
(to Recommendation M.251)
.sp 9p
.RT
.ce 0
.ce 1000
\fBProtection, restoration\fR
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
(under study)
\v'2P'
.ce 0
.sp 1P
.ce 1000
ANNEX\ D
.ce 0
.ce 1000
(to Recommendation M.251)
.sp 9p
.RT
.ce 0
.ce 1000
\fBSupport of maintenance\fR
.sp 1P
.RT
.ce 0
.sp 1P
.ce 1000
(under study)
\v'2P'
.ce 0
.sp 1P
.sp 2P
.LP
\fBReferences\fR
.sp 1P
.RT
.LP
[1]
CCITT Recommendation \fIMethodology for the specification of the\fR
\fIman\(hymachine interface\ \(em\ Tools and methods\fR , Vol.\ X, Rec.\ Z.333.
.LP
[2]
CCITT Recommendation \fIIntroduction to the specification of the\fR
\fIman\(hymachine interface\fR , Vol.\ X, Rec.\ Z.331.
.LP
[3]
CCITT Recommendation, \fIMethodology for the specification of the\fR
\fIman\(hymachine interface\ \(em\ General working procedure\fR , Vol.\
X, Rec.\ Z.332.
.LP
.rs
.sp 19P
.LP
.bp
.LP
\fBMONTAGE:\ \fR PAGE 234 = PAGE BLANCHE
.sp 1P
.RT
.LP
.bp